home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000552_connolly@pixel.convex.com _Tue Jan 12 23:10:06 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Return-Path: <connolly@pixel.convex.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA26846; Tue, 12 Jan 93 23:10:06 MET
  4. Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA09740; Tue, 12 Jan 1993 23:25:13 +0100
  6. Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
  7.     id AA13978; Tue, 12 Jan 93 16:25:09 -0600
  8. Received: from localhost by pixel.convex.com (5.64/1.28)
  9.     id AA02411; Tue, 12 Jan 93 16:25:08 -0600
  10. Message-Id: <9301122225.AA02411@pixel.convex.com>
  11. To: "Thomas A. Fine" <fine@cis.ohio-state.edu>
  12. Cc: timbl@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
  13. Subject: Re: HTML todo list 
  14. In-Reply-To: Your message of "Tue, 12 Jan 93 16:42:55 EST."
  15.              <9301122142.AA13427@soccer.cis.ohio-state.edu> 
  16. Date: Tue, 12 Jan 93 16:25:07 CST
  17. From: Dan Connolly <connolly@pixel.convex.com>
  18.  
  19.  
  20. >I'd also like to express the opinion that we shouldn't make the HTML so
  21. >terribly specific.  Every new situation shouldn't require another addition
  22. >to HTML.  If that were the case, we'd never be finished.
  23.  
  24. Well, suffice it to say that HTML doesn't give much semantic
  25. information. It would be nice to express relationships between
  26. pieces of information through the document structure, but in
  27. HTML we mostly use links.
  28.  
  29. >>[...] The same is true for newlines: it's
  30. >>illegal to treat
  31. >><foo>
  32. >>content
  33. >></foo>
  34. >>different from <foo>content</foo> because the difference is
  35. >>not reported by the parser (unless we do some shortref magic
  36. >>to force the parser to report the difference.)
  37. >
  38. >I don't think we should do any shortref magic.  The simplest thing
  39. >(the way it works now) is that the two examples above are identical.
  40. >I say this is fine.
  41.  
  42. But it's a royal pain to implement! Doing full SGML newline processing
  43. by the standard is quite involved (see the article by Eric Naggum
  44. in comp.text.sgml about SGML and Records that I referenced in
  45. an earlier message). For example, you can't just get rid of all
  46. newlines immediately before or after tags, like it says in the
  47. web: Only those right after a start tag (of a non-empty element),
  48. right before an end tag,
  49. or the ones on a line containing only comments and processing instructions.
  50. Newlines around <P> tags, for example, _are_ reported.
  51.  
  52. If we don't stick the SHORTREF magic in the DTD to force the
  53. parser to report all newlines, we'll end up with countless hacks
  54. at newline processing, none of which matches the standard, and
  55. it'll be luck if any of them matches each other.
  56.  
  57. Dan
  58.